In the Policy Control and Charging (PCC) architecture of the 3rd Generation Partnership Project (3GPP), a network element of a core network, which is a Packet Gateway (PGW) interacts with a Policy and Charging Rule Function (PCRF) entity via a Gx interface to create an Internet Protocol (IP)-Connectivity Access Network (CAN) session and to perform policy control. FIG. 1 illustrates a flow of creating an IP-CAN session. The PGW transmits a Credit-Control-Request (CCR) message to the PCRF entity to request for creation of an IP-CAN session, and the PCRF entity feeds a Credit-Control-Answer (CCA) message back to the PGW to acknowledge creation of the IP-CAN session.
During the session is being maintained, the PCRF entity can transmit a Re Auth Request (RAR) message to the PGW to request for reauthorization of PCC rules or for update of a list of report events, and the PGW responds to the RAR message by feeding back a Re Auth Answer (RAA) message to the PCRF entity, as illustrated in FIG. 2.
A pre-load mode refers to that the PCRF entity transmits respective PCC rules (including validation time and invalidation time of each rule), for PCC control on a related service for different periods of time, to the PGW at a time. The PGW itself controls the PCC rules to be enforced for the current time. The PCC rules can be issued and enforced in the preload mode to thereby decrease signaling interaction between the PCRF entity and the PGW and improve the processing efficiency, which is applied to a scenario where respective PCC rules for busy and idle time are enforced. As illustrated in FIG. 3, in the preload mode, the PGW transmits a Credit-Control-Request-Initial (CCR-I) message to the PCRF entity to request for creation of a session, the PCRF entity feeds a CCA-I message (including validation time and invalidation time of PCC rule) back to the PGW, and the PGW starts enforcement of a corresponding PCC rule at the validation time of the PCC rule in a Credit-Control-Answer-Initial (CCA-I) message and terminates the PCC rule at the invalidation time of the PCC rule.
In the preload mode, the validation time and the invalidation time of the PCC rule issued by the PCRF entity have to specify corresponding particular date and time (i.e., particulate year/month/day/hour/minute/second), for example, validation time of some PCC rule is 8:00:00 on Dec. 12, 2012, and invalidation time thereof is 16:00:00 on Dec. 12, 2012. Since each of the PCC rules, provided by the PCRF entity, to be enforced by a Policy and Charging Enforcement Function (PCEF), can only be enforced for policy control on the corresponding service for some period of time on a particular preset date in the preload mode, the PCC rule will be invalidated once the particular preset date elapses. Thus this approach to issue the PCC rule can not be applicable if time universality is required.
For example, some PCC rule needs to be enforced from 8:00:00 to 16:00:00 every day in the preload mode, so a particular year/month/day (i.e., a particular date) on which the service is enforced may not be specified as long as a hour/minute/second at which the service is started and a hour/minute/second at which the service is terminated (i.e., a particular period of time) are specified.
In the prior art, although the control on the PCC rule is transferred to the PGW in the preload mode, and the PCRF entity only needs to initially configure the PGW with the related PCC rule information. However, it is specified in the protocol that the validation time and the invalidation time of the PCC rule must be in correspondence to some particular year/month/day/hour/minute/second, and the PGW can not perform PCC control on the corresponding service after the validation date corresponding to the PCC rule elapses. If it needs to perform PCC control again on the corresponding service, then the PGW has to transmit a CCR message again to request for issuance of the PCC rule. Thus the enforcement time preset for the PCC rule can take effect only once instead of being applied repeatedly in the preload mode in the prior art, thus increasing the consumption and overhead of signaling and also the consumption of system resources to thereby greatly degrade the value of applying and popularizing the preload mode.